Это, по-сути, средство сбора отчетности о виртуальной инфраструктуре VMware vSphere и виртуальных машинах, что-то вроде бесплатного Veeam Reporter Free.
В категории Performance мы можем увидеть следующую информацию:
Host/VM Utilization Heat Map - в этой категории представлены хосты и виртуальные машины с наибольшей загрузкой вычислительных ресурсов. Весьма полезно для развертывания новых ВМ.
Host Top CPU Ready Queue - параметры метрики производительности CPU Ready. Подробнее об этом счетчике тут.
Storage Access IOPS - здесь мы видим нагрузку на виртуальные хранилища по IOPs (на и из Datastore).
В категории Efficiency мы можем увидеть следующую информацию:
VM Over/Under Provisioning - показывает недогруз или перегруз по ресурсам для виртуальных машин на хост-серверах.
Storage Wasted Allocations - ранжированно показывает, где у нас на хранилище лежит непойми что (не относящееся к ВМ) и их недозаполненность.
Storage Allocated to Dormant VMs - показывает какие ВМ не используются и сколько выделено под них хранилища.
VM Rightsizing Recommendations - показывает рекомендации по сайзингу ВМ с точки зрения производительности (типа добавить или удалить vCPU).
Но этот продукт для небольшой инфраструктуры, а нормальные пацаны с табуном серверов ESX / ESXi скачивают и покупают продукт Veeam Reporter, который позволяет вести трекинг изменений виртуальной инфраструктуры VMware vSphere и получать отчетность обо всех ее аспектах. Тем более, что недавно вышел бесплатный аддон к нему - Capacity Planning Report pack for Veeam Reporter.
Скачать же бесплатный VMTurbo Performance and Efficiency Reporter можно по этой ссылке.
Как вы знаете, VMware vSphere 5 будет построена только на базе гипервизора VMware ESXi (а ESX больше не будет) и выйдет уже в этом году, поэтому мы публикуем серию заметок о том, как перейти на ESXi с ESX (вот тут - раз и два).
Сегодня мы поговорим о таком различии, как Scratch Partition в ESXi. Scratch Partition - это специальный раздел на хранилище для хост-сервера, который не обязательно, но рекомендуется создавать. Он хранит в себе различную временную информацию для ESXi, как то: логи Syslog'а, вывод команды vm-support (для отправки данных в службу поддержки VMware) и userworld swapfile (когда он включен). Он создается, начиная с vSphere 4.1 Update 1 автоматически, и, если есть возможность, на локальном диске.
Так как данный раздел является необязательным, то в случае его отсутствия вся перечисленная информация хранится на ramdisk хост-сервера (который, кстати, отъедает память - 512 MB). И, так как это ramsidk, после перезагрузки эта информация (если у вас нет scratch partition) очищается. Поэтому неплохо бы этот раздел, все-таки, создать.
По умолчанию, этот раздел создается в системе vfat и составляет 4 ГБ. Это много. Почему так много? Объяснение такое, что местечко оставлено под будущие версии ESXi. Этот раздел может размещаться локально или на SAN-хранилище. При этом его могут использовать несколько хостов ESXi одновременно, поэтому рекомендуется сделать его гигов 20. Но для каждого должна быть своя locker-директория на этом разделе.
Через vSphere Client scratch partition настраивается так:
Соединяемся с хостом ESXi из vSphere Client.
Переходим на вкладку Configuration.
Переходим в категорию Storage.
Нажимаем правой кнопкой на datastore и выбираем Browse.
Создаем уникальную директорию для хоста ESXi (например, .locker-ESXiHostname)
Закрываем Datastore Browser.
Переходим в категорию Software.
Нажимаем Advanced Settings.
Переходим в раздел ScratchConfig.
Устанавливаем в качестве значения ScratchConfig.ConfiguredScratchLocation директорию, которую только что создали, например:
/vmfs/volumes/DatastoreName/.locker-ESXiHostname
Нажимаем OK.
Перезагружаем ESXi.
Все это можно настроить и при автоматизированном развертывании VMware ESXi через kickstart. А можно и через vCLI и PowerCLI. О том, как это сделать, читайте в KB 1033696.
Слышали про такую проблему VDI Boot Storm? Вот у вас есть инсталляция системы виртуализации корпоративных ПК предприятия (например, на базе VMware View 4.x) на несколько десятков или даже сотен пользователей виртуальных ПК. В 8:00 у вас начинается рабочий день - пользователи приходят за свои рабочие места и одновременно включают свои виртуальные десктопы. В результате возникает серьезная нагрузка на систему хранения, где эти самые образы виртуальных ПК хранятся (десятки, сотни машин на сторадже).
И получается вот такой VDI Boot Storm - машины тормозят, сессии отваливаются, пользователи жалуются. Ведь при загрузке Windows 7 генерирует где-то 50-100 IOPS, а при обычной офисной работе это значение составляет 5-15 IOPS. Наглядно это выглядит так:
Что же делать с этим VDI boot storm?
Ну, во-первых, вы должны это обязательно учитывать при планировании развертывания инфраструктуры виртуальных ПК. Ваша инфраструктура хранения FC или iSCSI должна учитывать такие пиковые нагрузки, и начало рабочего дня - отличный способ это проверить. Есть также вот инструмент VDI Sizing Tool (VST) от нашего соотечественника, который позволяет мерить нагрузку для VDI-сценариев.
Во-вторых, SSD-диски. Да, дорого. Но иногда без них нельзя. Если вы используете VMware View с функциональностью View Composer для создания связанных клонов виртуальных ПК на основе базового образа - вам поможет концепция ярусного хранения данных, реализованная в продукте. На быстрые SSD-накопители можно помещать реплики пулов виртуальных ПК и Disposable-диски виртуальных машин. Сравните 150-200 IOPS у SAS-дисков с 5000 у SSD.
В-третьих, есть специализированные решения, такие как, например, NSS SAN Accelerator for VMware View. Эта штука представляет собой железку с SSD-дисками, которая ставится между хост-серверами VMware ESX / ESXi и системой хранения. Она умеет автоматически кэшировать наиболее часто используемые блоки и выравнивать нагрузку по хост-серверам.
В четвертых, есть мысль, что перед тем, как пользователь пришел на работу, его виртуальный ПК уже должен быть готов к работе и запущен. Мысль самая разумная, но почему-то нормальная настройка этого механизма в VMware View отсутствует. Вроде как даже из интерфейса View 4.5 убрали шедулинг запуска виртуальных ПК. А какого-то централизованного механизма вроде нет. Или есть? Может вы подскажете?
Как мы уже писали, компания StarWind готовится к выпуску версии StarWind Enterprise 5.7, которая будет иметь несколько новых возможностей. О продукте StarWind Enterprise можно почитать тут, тут и тут.
А на днях стала доступна публичная бета-версия StarWind Enterprise 5.7, которую можно скачать в рамках программы тестирования. В статье приведены новые возможности, которые точно появятся в StarWind 5.7.
Автор сайта vdi-sizing.com, Василий, прислал нам ссылку на свою утилиту VDI Sizing Tool (VST), которая позволяет тестировать производительность и возможности консолидации виртуальных ПК (например, VMware View 4.x).
Эта утилита имитирует пользовательскую нагрузку в виртуальных ПК и измеряет время различных событий (старт приложений, создание RDP-сессии и т.д.), по результатам чего можно принять решение о выборе необходимого решения для виртуализации настольных ПК (сейчас их несколько, наиболее популярные - VMware View и Citrix XenDesktop).
VDI Sizing Tool содержит два компонента - user workload и loadmaster. User workload запускается в каждом тестируемом виртуальном ПК и симулирует обычные пользовательские действия - открытие документов MS Office, работу в браузере и т.п.
Loadmaster - запускается на стороне клиента виртуального ПК (например, там, где установлен VMware View Client) и тестирует соединение по RDP: собирает информацию о производительности при удаленной работе (latency), а также контролирует работу агентов LoadSlave, если используется мультиклиентное тестирование (в целях повышения объективности результатов).
Интересно, что в разделе Download можно найти документ "Sample measurements", где приведены результаты работы программы.
А в следующей версии VST автор обещает нам новые возможности:
Поддержка новых приложений в качестве нагрузки: PDF viewers, archivers и т.п.
Workload customization
Счетчики и метрики производительности для популярных VDI-решений: VMware, Microsoft и Citrix
Автоматизация развертывания виртуальных ПК (клонирование виртуальных машин и т.п.)
Скачать VDI Sizing Tool можно по этой ссылке. Можете в комментариях позадавать автору вопросы - я думаю, он постарается ответить.
Вы уже знаете, что не так давно вышли окончательные версии платформы Microsoft Windows Server 2008 R2 SP1 и бесплатной ее версии Hyper-V Server 2008 R2 SP1, ориентированной только на задачи виртуализации. Одно из основных нововведений - функции Dynamic Memory для виртуальных машин, позволяющие динамически выделять и распределять оперативную память между ними.
Kenny Coleman, один из блоггеров, пишущий о виртуализации VMware, выпустил пакет утилит для администраторов виртуальной инфраструктуры vSphere / ESX под названием VM Advanced ISO. Пакет содержит в себе набор необходимых программ для рутинных задач с виртуальными машинами:
Утилиты 1 - P2V Clean-up
01 - Resolution Resize (меняем разрешение гостевой ОС)
02 - HP ProLiant Cleaner (вычищаем софт HP после миграции в ВМ)
Бывает такое, что при резервном копировании виртуальной машине VMware vSphere на томе NFS (не VMFS!) виртуальная машина перестает отвечать на пинги, консоль подвисает и с ней не соединиться по RDP.
Такие вещи случаются, когда вы используете Veeam Backup and Replication 5 в режиме Changed Block Tracking (CBT), то есть с отслеживанием изменившихся блоков для более быстрого резервного копирования. Связано это с особенностями работы NFS-лочек, которые могут "провисать" до 30 секунд, в течении которых машина и зависает.
Если это вас так сильно беспокоит, Changed Block Tracking можно просто отключить в настройках задачи резервного копирования Veeam Backup and Replication:
Но если отключите CBT - бэкапы будут делаться медленнее. Так что выбирайте.
Если речь идет о мониторинге производительности ОС на аппаратной («железной») платформе, то мало у кого возникает вопрос как это делать. Существуют уже давно известные инструменты и способы мониторинга таких систем. Но вот когда речь заходит о мониторинге производительности гипервизора с запущенными на нем виртуальными машинами, тут уже не все так однозначно, а особенно с гипервизором Hyper-V от компании Microsoft. Таги: Microsoft, Hyper-V, Performance, Производительность, VMachines, SCOM
Вы, наверняка, слышали про компанию VKernel, которая производит средства для управления виртуальной инфраструктурой VMware vSphere. Исторически сложилось так, что продукты компании часто перекрываются их аналогами со стороны VMware (например). Вот и не так давно вышел в свет продукт VKernel Performance Analyzer 1.0, являющийся частью пакета vOperation Suite. Он является прямым конкурентом VMware vCenter Operations, о котором мы писали на прошлой неделе.
Предназначен VKernel Performance Analyzer для обнаружения проблем в виртуальной инфраструктуре vSphere в реальном времени на базе алармов VMware vCenter. Приводится детальное описание проблемы производительности объекта (например, виртуальной машины), а дальше предлагается, что с этой виртуальной машиной можно сделать (а в колонке Action предлагается действие, которое можно сделать прямо из интерфейса программы):
Зацените, кстати, имена машин русские - это все потому, что чуваки сидят под Москвой.
Небольшой обзор о функционале VKernel Performance Analyzer 1.0:
Требования к VKernel Performance Analyzer такие:
VMware ESX 3.0 и vCenter 2.5 и выше
1 vCPU если у вас меньше 200 ВМ, 2 vCPUs если у вас 200-1500 ВМ, 4 vCPUs - более 1500 ВМ
3 ГБ памяти
10 ГБ дискового пространства
Что умеет VKernel Performance Analyzer:
Мониторинг тревог vCenter с рекомендациями по разрешению проблем
Поиск виртуальных машин и других объектов (например, Datastore), испытывающих проблемы с производительностью
Решение проблем в один клик за счет действий, выполняемых при интеграции с vCenter
Карта узких мест виртуальной инфраструктуры (недостаток ресурсов)
Отчет о проблемах производительности инфраструктуры с указанием путей их устранения
Alarm by Virtual Object Heat Map - проблемы производительности выраженные через алармы vCenter для всех объектов vSphere
Нотификации по трендам загрузки
Графики использования ресурсов для объектов
vCenter Alert Auto-configurator - установка алармов vCenter в соответствии с лучшими практиками
Обзорное видео по продукту:
Скачать VKernel Performance Analyzer можно по этой ссылке.
P.S. Кстати, Милош, хватит там отсиживаться - давайте уже покупайте рекламу на VM Guru. О вас тут мало кто знает, а реклама - это двигатель сам знаешь чего. Для кого тут баннер справа висит:)
Компания VMware на прошлой неделе выпустила продукт VMware vCenter Operations, который позволит системным администраторам и менеджерам датацентров обнаруживать, анализировать и решать проблемы производительности VMware vSphere.
vCenter Operations собирает данные о производительности каждого из объектов виртуальной инфраструктуры VMware vSphere (виртуальные машины, хранилища, кластеры, датацентр в целом), хранит их в централизованной базе данных, анализирует их и делает отчет в реальном времени о текущих проблемах производительности, а также о потенциальных проблемах.
Есть разные представления данных:
Основные особенности vCenter Operations:
Комбинирование ключевых метрик производительности в общее количество баллов для датацентра (CPU, memory, disk, contention performance).
vCenter Operations вычисляет диапазон значений, который находится в рамках допустимой производительности, и подсвечивает отклонения от этого диапазона.
Графическое представление инфраструктуры в контексте производительности с возможностью "проваливания" до отдельных компонентов.
Отображение информации об изменениях в иерархии виртуальной инфраструктуры, после чего vCenter Operations показывает, как эти изменения отразились на производительности различных объектов. Например, если виртуальная машина переместилась за счет vMotion между хостами VMware ESX, vCenter Operations покажет нам как изменилась нагрузка на хост-серверы.
Обзорное видео:
В продукте три основных аспекта представления информации о производительности виртуальной инфраструктуры vSphere:
health - текущее состояние объекта или всего виртуального датацентра. Им назначаются очки, исходя из допустимых значений нормальной производительности, а также на основе исторических данных. Если показатели метрик выходят за данные значения - vCenter Operations оповещает об этом и сообщает о возможных причинах.
analytics - на основе загрузки текущих метрик с помощью данного представления можно определить, какие объекты простаивают (например, хост-серверы), а какие требуют выделения дополнительных ресурсов (например, виртуальная машина).
capacity - показывает какой процент емкости от физических ресурсов занимает тот или иной объект. Далее за счет модуля аналитики можно узнать время, когда ресурсов окажется недостаточно (например, заполнится Datastore) и сделать долгосрочные прогнозы по добавлению новых мощностей в инфраструктуру (вычислительные ресурсы, хранилища).
vCenter Operations поставляется в 3-х изданиях: Standard, Advanced и Enterprise:
Standard
Advanced
Enterprise
Performance Management
Alerting and Visualization
Consolidated Health dashboard
Actionable health scores & KPIs
Top N priority views
Self learning behavior
Dynamic Thresholds
Early warning visualizations
Predictive 'Smart' Alerts
Alert lifecycle mgmt
Custom alerts
Email & SNMP notifications
Analysis & Troubleshooting
1 click root-cause dashboard w/ KPI history
Impact detection (Health trees)
Behavioral performance/workload analysis
Multiple KPI anomaly correlation
Contextual event overlays
HeatMap library
Cross Team views & enablement
Role based access & SSO
Actionable operator views
Problem isolation tools
Report by Custom Groups
vSphere awareness
Multi vCenter support
Integrated into vSphere Client
vSphere Inventory & dependency aware
Support for Reservations & Limits
Capacity Management
Capacity Awareness
Past, present, future capacity summaries
Current capacity bottlenecks
Future capacity shortfall notifications
Alerts on capacity conditions
Schedulable Capacity Reports
Report across multiple vCenters
Capacity Optimization
Analyze & trend resource wastage
Identify over-allocated, idle VMs
Identify under-utilized hosts, clusters
Identify waste from snapshots, templates, orphaned
VMs
Recommendations to reclaim resources
Recommendations to rightsize
Capacity Planning & Forecasting
Estimate remaining capacity
Estimate time remaining to full capacity
Forecast demand & supply
Trend Utilization vs demand
Trend Utilization and allocation
Replenishment recommendations
Interactive What-if modeling
Support for vSphere storage
Support for Peak usage
Support for Business time zones
Cross Team views & enablement
Role based access & SSO
Actionable operator views
Report by Custom Groups
Infra. utilization trend views for Upper mgmt
Supply forecast for provider teams: Storage, Network, Build
Usage & Optimization views for LOB
Cloud capacity reports for Provider & Tenants
Report customization
vSphere awareness
Integrated into vSphere Client
vSphere Inventory & dependency aware
Support for vCloud objects(vDCs)
Support for Thin Provisioning
Support for Reservations & Limits
Support for Linked Clones
Support for HA, FT
Configuration & Compliance Management
Configuration Visibility
Configuration and change visibility
Centralized dashboards
Out of box Reports
Change alerts
Continuous Compliance
Guest Compliance
Host Compliance
vCenter Compliance
Standard Regulatory compliance (SOX, HIPAA, DISA, ISO, BASEL II, PCI DSS, NIST)
Custom policy compliance
Automated compliance violation detection
Compliance remediation recommendations
Compliance remediation automation
Automated Provisioning and Patching
Manage OS distribution centrally
Discover new systems, build/deploy via PXE
Provision ESX/ESXi to "bare metal"
Provision OS to bare metal & VMs
Build and deploy software packages (Windows)
Connect to compliance policies
Automatically detect missing software
Remediate non-compliant systems
Distributed software repository
Cross Team Views & enablement
Role based access control
Active Directory integration
Скачать vCenter Operations с сайта VMware нельзя. Для запроса детальной информации обращайтесь к партнерам компании VMware.
Как мы уже писали, в VMware vSphere 4.1 появилась технолония Storage IO Control (SIOC, подробности здесь), которая позволяет настраивать приоритеты доступа виртуальных машин к хранилищам не в рамках одного хоста VMware ESX / ESXi, а в рамках всего кластера.
и какие рекомендации по настройкам Latency можно использовать при борьбе виртуальных машин за ресурсы ввода-вывода, в зависимости от типов хранилищ:
Второй документ называется "Managing Performance Variance of Applications Using Storage I/O Control". Он содержит результаты тестирования SIOC в условиях, когда нужно выделить виртуальную машину как критичную с точки зрения ввода-вывода (отмечена звездочкой). Взяли требовательную к нагрузкам задачу (DVD Store).
Измерили эталонную производительность когда работает только критичная ВМ (левый столбик - принят за единицу, SIOC Off), измерили среднуюю производительность (когда все машины работают параллельно и у каждой Shares установлено в 1000, SIOC Off), а потом стали варьировать Shares для критичной виртуальной машины (при включении SIOC On) смотря на то, как растет ее производительность в рамках кластера:
Видим, что SIOC при распределении приоритета ввода-вывода между хостами работает. В этом же документе есть еще тесты, посмотрите.
Часто разговаривая с заказчиками и пользователями платформ виртуализации от VMware, я вижу, что у многих из них весьма широко применяются снапшоты (snapshots), в том числе для целей "резервного копирования". Эти снапшоты живут долго, их файлы разрастаются и поростают плесенью. Потом инфраструктура начинает тормозить, а пользователи не знают почему. И как это не казалось бы странным - удаление всех снапшотов у всех виртуальных машин решает их проблемы, с которыми они уже свыклись.
Сегодня я вам расскажу, чтоб вы наконец запомнили: снапшоты это в целом плохо и лишь иногда хорошо. На эту страницу мы с вами будем отсылать наших клиентов и пользователей виртуальных машин, которыми могут оказаться люди, не участвующие в процессе администрирования VMware vSphere, но пользующиеся функционалом снапшотов (например, веб-разработчики).
Начнем с того, когда снапшоты могут помочь (я имею в виду, конечно, руками делаемые снапшоты, а не автоматические, которые делает, например, Veeam Backup). Снапшоты в VMware vSphere оказываются полезны в очень ограниченных условиях (например, для проверки корректности работы обновления приложения или патча операционной системы). То есть эта та точка сохранения состояния виртуальной машины, к которой можно будет вернуться через небольшой промежуток времени. Ни в коем случае нельзя рассматривать снапшоты как альтернативу резервному копированию основных производственных систем, в силу множества проблем, о которых пойдет речь ниже.
Что плохого в снапшотах виртуальных машин на VMware ESX:
1. Снапшоты неконтролируемо растут (блоками по 16 МБ). Помимо базового диска ВМ фиксированной емкости вы имеете еще один файл отличий виртуального диска, который растет как ему вздумается (предел роста одного снапшота - размер базового диска). Особенно быстро растут снапшоты для ВМ с приложениями с большим количеством транзакций (например, почтовый сервер или сервер СУБД). Со снапшотами вы не имеете контроля над заполненностью хранилищ.
2. Большое количество снапшотов (особенно цепочки, в которых может быть до 32 штук) вызывает тормоза виртуальной машины и хост-сервера ESX (в основном замедляется работа с хранилищем). Проверено на практике. Даже VMware пишет так: "An excessive number of snapshots in a chain or snapshots large in size may cause decreased virtual machine and host performance". В качестве примера можно привести тот факт, что при аллокации блоков снапшота происходит блокировка LUN (в этом режиме он доступен только одному хосту, остальные ждут). Когда снапшот делается - машина подвисает из-за сброса памяти на диск.
3. Снапшоты не поддерживают многие технологии VMware, созданные для автоматизации датацентров. К ним относятся VMware Fault Tolerance, Storage VMotion и другие. Когда одни машинки в чем-то участвуют, а другие не участвуют - это нехорошо в рамках концепции динамической инфраструктуры.
4. Снапшоты вызывают специфические проблемы при операциях с ВМ. Например, расширение диска виртуальной машины со снапшотом приводит к потере данных и непонятками, что дальше с такой машиной делать. Сто раз уже пользователи влипали (вот как вытянуть себя за волосы). Интересно также восстановить из снапшота машину с IP-адресом, который на данный момент уже используется в сети.
5. Со снапшотами бываютбаги, а бывает, что они просто "by design" тупят.
1. Контролируйте наличие снапшотов у виртуальных машин и их размеры, своевременно удаляйте их совместно с владельцами систем. Делать это можно, например, с помощью RVTools.
2. Не храните снапшоты больше 24-72 часов. Этого времени достаточно, чтобы оттестировать обновление ПО или патч ОС (ну и, конечно, сделать бэкап).
3. На сервере VMware vCenter можно настроить алармы на снапшоты виртуальных машин. Сделайте это. Дрючьте пользователей за необоснованные снапшоты.
4. Не позволяйте делать больше 2-3 снапшотов для виртуальной машины в принципе, если это делается в производственной среде. На своих выделенных для тестирования ресурсах (изолированных) пусть разработчики делают что хотят.
5. Если вы используете ПО для резервного копирования через снапшоты ВМ (например, Veeam Backup), помните, что бывает некоторые невидимые в vSphere Client снапшоты (Helpers) остаются на хранилище. Поглядывайте за машинами из командной строки.
Хорошая статья "Optimising PCoIP Display & Imaging" появилась на сайте myvirtualcloud.net. Ее основная суть - как с помощью групповых политик можно управлять различными параметрами PCoIP в целях оптимизации производительности виртуальных ПК VMware View 4.5. Особенно актуальны эти настройки для WAN-соединений, где PCoIP в сравнении с тем же Citrix HDX/ICA показывает не самые лучшие результаты.
Вот каких параметров можно добавить в реестр виртуальной машины VMware View (тип REG_DWORD) и через групповые политики:
PColPMaxLinkRate GPO (pcoip.max_link_rate)
Это значение максимальной ширины канала для сессии PCoIP в килобитах в секунду. По умолчанию это значение в 1 Gbps. Значение 0 - отменяет ограничения по ширине канала.
По умолчанию установлено значение в 30 кадров в секунду (fps). Это основной параметр, который следует регулировать в окружениях, ограниченных по пропускной способности канала. Если у вас канал очень узкий, а машин в него должно влезть много - регулируйте максимальное число кадров в секунду (но про качество картинки тоже не забывайте). На практике одна машинка без видео и других тяжелых для VDI нагрузок кушает где-то 200-300 Kbps.
Обнаружилась интересная бесплатная утилита HyperV_Mon, которая позволяет наблюдать за производительностью серверов Microsoft Hyper-V и своевременно обнаруживать проблемы:
HyperV_Mon 1.8 показывает ресурсы (CPU, Memory, I/O), используемые root partition и гостевыми системами виртуальных машин, а также накладные расходы гипервизора. Версия 2.0 будет поддерживать уже Hyper-V R2, который будет в Windows 2008 R2 SP1, планируемый к релизу в ближайшее время. Скачать HyperV_Mon 1.8 можно по этой ссылке.
Константин Введенский, мой старый приятель и по совместительству сотрудник компании StarWind Software, опубликовал интересные заметки по оптимизации работы хранилищ виртуальных машин VMware ESX на базе продукта StarWind Enterprise. Если кто-нибудь из вас все еще не знает как StarWind может помочь вам в создании отказоустойчивых систем хранения по iSCSI для виртуальных машин серверов VMware ESX, то вам сюда, сюда, и, вообще, сюда.
О чем говорят нам эти заметки:
1. iSCSI Initiator на VMware ESX можно использовать в режиме NIC binding (то есть Teaming в настройках vSwitch), или в режиме MPIO (multipathing, в настройках политики путей к хранилищу в категории Storage), но нельзя их использовать одновременно. Еще посмотрите сюда.
2. Если вы используете и хранилища NAS/NFS, и хранилища iSCSI, то нужно использовать NIC Teaming для обоих интерфейсов, а не MPIO.
3. Для типа балансировки IP Hash вы сможете использовать только 1 iSCSI-соединение на хост VMware ESX. Как настраивается тип балансировки IP Hash изложено в KB 100737.
4. По умолчанию время выбора пути в случае отказа на VMware ESX равно 300 секунд. Это время рекомендованное VMware. Вы можете уменьшить или увеличить это время. Его уменьшение ускорит переключение на резерв, но даст нагрузку на процессор ESX (более частый опрос путей), увеличение этого времени снизит нагрузку на CPU, но и увеличит время Failover'а. Настраивается этот параметр в Advanced Settings сервера ESX - он называется Disk.PathEvalTime, и его значение может варьироваться в диапазоне от 30 до 1500. Более подробно в VMware KB 1004378 и еще вот тут посмотрите, например.
5. В виртуальных машинах Windows убедитесь, что параметр Disk\TimeOutValue в реестре равен 60 секундам. Это позволит дисковому устройству не отваливаться раньше времени. Если VMware Tools установлены, то он будет равен 60 секундам после установки, если же нет, то это будет 10 секунд (non-cluster) или 20 секунд (cluster node). Настраивается он вот в этом ключе реестра:
Для Linux все немного не так. Без VMware Tools время TimeOutValue равно 60 секундам, а с ними - 180 секундам. Настраивается TimeOutValue в Linux так:
cat /sys/block/<disk>/device/timeout
Для большинства случаев подойдет значение в 60 секунд.
6. Для достижения лучшей производительности со StarWind Enterprise лучше использовать политику балансировки нагрузки по нескольким путям Round Robin (не активирована по умолчанию, по дефолту стоит политика Fixed). Для этого нужно щелкнуть правой клавишей по устройству iSCSI и нажать "Manage Paths" в vSphere Client.
Эта политика позволяет переключаться между путями каждые 1000 IOPS'ов. Можно уменьшить это значение для оптимизации производительности. Для этого в сервисной консоли ESX / ESXi наберите:
В данном случае выставлено 3 IOPS'а. UUID девайса можно узнать в категории "Storage adapters" в vSphere Client для сервера ESX. Опросить текущие настройки устройства можно командой сервисной консоли:
esxcli nmp roundrobin getconfig --device [UUID]
Ну и, конечно, помните, что все эти настройки нужно сначала опробовать в тестовой среде и посмотреть на изменения в производительности работы сервера ESX с хранилищем StarWind Enterprise.
Скачать StarWind Enterprise HA можно по этой ссылке, ну а покупают его только здесь.
Как обычно, Duncan Epping написал отличный пост об использовании памяти виртуальными машинами на хостах VMware ESX. Постараемся объяснить это на русском языке. Итак, если открыть вкладку Summary в vSphere Client для виртуальной машины, мы увидим вот такую картину:
Здесь есть 2 главных параметра:
Memory - это то количество оперативной памяти, которое вы выделили виртуальной машине при создании. За это количество гостевая ОС не выйдет при ее использовании. Это же количество памяти вы увидите в гостевой ОС.
Memory Overhead - это количество памяти, которое может потребоваться гипервизору на поддержание работы виртуальной машины сверх используемой памяти (т.е. расчетные накладные расходы на виртуализацию, но не текущие).
Далее мы видим панель Resources, здесь есть такие показатели:
Consumed Host Memory - это количество физической памяти хоста ESX, выделенной виртуальной машине. Обычно это значение не больше значения Memory на предыдущей картинке. Но может быть и больше, поскольку Consumed Host Memory включает в себя и Memory Overhead, но не с картинки выше, а реально используемый гипервизором Overhead (о котором будет идти речь ниже). И важный момент - счетчик Consumed для Memory на вкладке "Performance" не включает в себя Overhead.
Active Guest Memory - это количество памяти, которое по мнению гипервизора VMkernel активно используется гостевой операционной системой. Вычисляется этот параметр на базе статистических показателей. То есть, если ОС не очень активно использует память, то можно ей ее немного подрезать в условиях нехватки ресурсов.
Теперь идем на вкладку "Resource Allocation". Здесь все немного сложнее:
Появляются вот такие показатели:
Для Host Memory (видим, что это 2187 МБ = сконфигурированная память 2048 МБ + Overhead):
Consumed - это, опять-таки, объем потребляемой виртуальной машиной физической памяти хоста ESX (постоянно меняется). И он включает в себя накладные расходы гипервизора по памяти.
Overhead Consumption - это текущий объем затрат памяти на поддержание виртуальной машины (здесь 42 МБ в отличие от расчетного в 110 МБ)
А формула такова: Consumed = Private + Overhead Comsumption
Для Guest Memory (2048 МБ сконфигурировано в настройках):
Private - это объем памяти физически хранимый хостом для виртуальной машины (см. формулу выше).
Shared - это объем памяти, который отдается другим виртуальным машинам от разницы между сконфигурированным объемом (Configured Memory) и потребляемым (Consumed). Суть в том, что ОС Windows при загрузке очищает всю память виртуальной машины, но потом эти пустые страницы приложениями не используются. Поэтому гипервизор отдает их другим ВМ, пока ВМ, владеющая памятью не потребует их. Эти страницы и есть Shared. Как мы видим, Private + Shared = Guest Memory.
Swapped - это объем памяти, ушедший в файл подкачки vswp. То есть это не файл подкачки Windows, а файл подкачки в папке с виртуальной машиной. Само собой этот показатель должен быть нулевым или совсем небольшим, поскольку своппинг, который делает ESX (а точнее VMkernel) - это плохо, т.к. он не знает (в отличие от Windows), какие страницы нужно складывать в своп, поэтому кладет все подряд.
Compressed - это объем памяти, который получен после сжатия страниц с помощью механизма Memory Compression (то есть, хранимый в VM Compression Cache).
Ballooned - это объем памяти, который забрал balloon-драйвер (vmmemctl), чтобы отдать ее другим нуждающимся виртуальным машинам.
Unaccessed - это память, к которой гостевая ОС ни разу не обращалась (у Windows - это близко к нулю, так как она обнуляет память при загрузке, у Linux должно быть как-то иначе).
Active - опять-таки, активно используемая память на основе статистики гипервизора.
На хорошем и производительном хосте VMware ESX метрики Compressed, Ballooned, Unaccessed - должны быть около нуля, так как это означает что машины не борются за ресурсы (то есть не сжимают страницы и не перераспределяют память между собой). Ну и, конечно, если показатель Active маленький, стоит задуматься об урезании памяти (но сначала посмотрите в гостевую ОС, она лучше знает, чем гипервизор, все-таки).
Worst Case Allocation - это сколько будет выделено виртуальной машине при самом плохом раскладе (максимальное использование ресурсов), то есть вся память будет использоваться, да еще и накладные расходы будут (т.е., Configured + максимальный Overhead).
Overhead Reservation - это сколько зарезервировано памяти под Overhead гипервизором.
В самом конце августа 2010 года компания VMware объявила о приобретении компании Integrien, занимающейся разработкой решений для выявления проблем производительности виртуальной инфраструктуры. А вот теперь на сайте VMware появилась промо-акция, по условиям которой все покупатели VMware vSphere (кроме серии Essentials) получают бесплатно лицензии на 50 виртуальных машин для продукта Alive VM (и один год поддержки и подписки на обновления, SnS):
Как заявляется на сайте Integrien (который еще не стал частью корпоративного брендинга VMware), Alive VM - это средство для отслеживания работоспособности виртуальной инфраструктуры VMware vSphere, определения проблем производительности и "узких мест", а также аналитики в сфере доступных и необходимых вычислительных ресурсов.
Больше всего это похоже на игру, где нужно двойным кликом убирать шарики одного цвета в ряд (посмотрите, например, видео):
В целом, Alive VM - это такой общий Dashboard, в котором виден виртуальный датацентр VMware vSphere с его объектами (кластеры, виртуальные машины) в которые можно "проваливаться" и смотреть различные характеристики рабочей нагрузки, health-статуса и анализировать, какова загрузка вычислительных ресурсов и нужно ли еще их добавить в датацентр. Также можно видеть как изменилась производительность виртуальной машины вследствие каких-либо причин, и какое изменение конфигурации это вызвало.
Поставляется Alive VM в виде виртуального модуля (Virtual Appliance), также доступна версия для установки на сервер Windows Server. Все действия с фронтендом производятся через веб-интерфейс. Плюс не нужна отдельная база данных.
Условия акции - продукт бесплатно предоставляется для всех пользователей, купивших продукт VMware vSphere, участвующий в акции, в период с 23 ноября 2010 года по 1 марта 2011 года (лицензии на 50 наблюдаемых виртуальных машин).
Компания VMware выпустила 17-страничный документ "Performance of Virtualized SQL Server–Based VMware vCenter Database", где рассматриваются основные аспекты производительности базы данных Microsoft SQL Server для сервера VMware vCenter в виртуальной машине инфраструктуры vSphere.
Результаты:
Большинство требовательных к ресурсам операций базы MS SQL на виртуальном vCenter по производительности сравнимы с физической инсталляцией.
SQL Server–based vCenter, управляющий большим количеством хост-серверов ESX и кластеров, вполне может работать в виртуальной машине.
Базы данных MS SQL в общем случае работают почти без потери производительности в виртуальных машинах на vSphere 4.1.
Есть такая компания VMTurbo - они делают утилиты для виртуальной инфраструктуры VMware vSphere. Кое-что у них получается, кое-что нет, а вот на днях они выпустили 2 новых утилиты: Host Resolver 1.0 и Storage Reporter 1.0. Обе они построены на базе виртуальных модулей (Virtual Appliance) с ОС Novell SUSE Linux как часть пакета VMTurbo Integrated Management Suite для виртуальных сред VMware.
Эта утилита позволяет проанализировать окружение серверов VMware ESX, выявить проблемы в существующей инфраструктуре и предложить пути их решения - типа изменить число виртуальных CPU или переконфигурировать сетевые настройки. После этого можно исправить ошибки вручную или автоматически с помощью данной утилиты.
Эта утилита позволяет проанализировать использование виртуальными машинами систем хранения, понять основные параметры производительности при работе со стораджами (IOPS, Latency) и отслеживать основные их параметры с течением времени (заполненность, снапшоты и прочее). Кроме того, может выдавать рекомендации по необходимости внесения изменений в конфигурации хранилищ (например, расширение).
Данное ПО поставляется в виде виртуальной машины для развертывания на XenServer, которая позволяет отслеживать производительность сетевого взаимодействия и работу виртуальных машин с хранилищами (storage I/O и network I/O). Через веб-интерфейс можно получить информацию о следующих аспектах производительности:
Disk I/O performance utility - предоставляет следующую информацию: sequential read/writes и random read/writes с различными размерами блоков.
Network I/O performance utility - это модифицированная версия утилиты netperf. Позволяет мониторить пропускную способность сети и задержки.
Скачать Citrix XenServer Virtual Machine Performance Utility можно по этой ссылке.
Компания VMware выпустила очень полезный и нужный Performance Best Practices for VMware vSphere 4.1, который нужно прочитать каждому администратору более-менее серьезной виртуальной инфраструктуры серверов ESX. Содержание вполне конкретное:
Hardware for use with VMware vSphere
ESX and virtual machines
Guest operating systems
Virtual infrastructure management
Например:
To establish a network connection between two virtual machines that reside on the same ESX system, connect both virtual machines to the same virtual switch. If the virtual machines are connected to different virtual switches, traffic will go through wire and incur unnecessary CPU and network overhead
Интересно, что в документе есть рекомендации по выбору и оптимизации аппаратного обеспечения, которые нужно прочитать до покупки серверов и других компонентов виртуальной инфраструктуры.
Мы уже писали о команде esxtop для серверов VMware ESX, которая позволяет отслеживать основные параметры производительности хост-сервера и его виртуальных машин. Duncan Epping недавно добавил еще несколько интересных моментов в свое руководство по работе с утилитой esxtop, некоторые из которых мы сейчас опишем.
Итак:
1. Для того, чтобы использовать пакетный режим работы esxtop (batch mode), нужно использовать ключ -b:
esxtop -b >perf.txt
Это позволит вывести результаты команды esxtop в файл perf.txt. Для задания числа хранимых итераций используйте ключ -n (например, -n 100).
Очень удобно для сбора исторических данных производительности на хосте VMware ESX.
2. Контролируйте счетчик %SYS - он показывает загрузку системных ресурсов хоста (в процентах). Рекомендуется, чтобы он не превышал 20 для системных служб.
3. Для установки частоты обновлений результатов esxtop используйте клавишу <s>, далее задавайте интервал в секундах:
В пакетном режиме этот интервал задается ключом -d (например, -d 2).
4. Для отслеживания метрик конкретной виртуальной машины можно ограничить вывод конкретным GID. Например, чтобы посмотреть ВМ с GID 63, нажмите клавишу <l> (list) и введите этот GID:
5. Чтобы ограничить количество выводимых сущностей, используйте клавишу <#>. Например, можно сделать вывод первых 5:
И сами кнопки в режиме работающей esxtop:
c = cpu
m = memory
n = network
i = interrupts
d = disk adapter
u = disk device (включая NFS-девайсы)
v = disk VM
y = power states
V = показывать только виртуальные машины
e = раскрыть/свернуть статистики CPU для конкретного GID
k = убить процесс (только для службы техподдержки!)
l = ограничить вывод конкретным GID (см. выше)
# = ограничить число сущностей (см. выше)
2 = подсветка строчки (двигает фокус вниз)
8 = подсветка строчки (двигает фокус вверх)
4 = удалить строчку из результатов вывода
f = добавить/удалить колонки
o = изменить порядок колонок
W = сохранить сделанные изменения в файл конфигурации esxtop
? = помощь для esxtop
Для тех, кто следит за развитием продуктов для виртуализации настольных ПК VMware View и Citrix XenDesktop, аналитическая компания Gartner подготовила интересное сравнение быстродействия протоколов VMware View (протокол PCoIP) и Citrix XenDesktop (протокол ICA / HDX) в сетях LAN и WAN.
Вывод - в LAN быстродействие приблизительно одинаковое, а вот в WAN-соединениях однозначно выигрывает Citrix XenDesktop. Вот одно из четырех сравнений для XenDesktop 4.0 Service Pack 1 и VMware View 4.5 :
Наконец-то. Компания VMware выпустила открытый и достаточно полный документ VMware View Optimization Guide for Windows 7, в котором рассказывается о том, как правильно подготовить виртуальные ПК с гостевой ОС Windoows 7 для использования в рамках VDI-решения на вашем предприятии.
Наши инженеры всерьез озаботились тем, как же правильно подготовить гостевую операционную систему виртуальной машины с учетом специфики решения для виртуализации настольных ПК VMware View 4.
Публичных хороших рекомендаций на данный момент несколько:
Как вы знаете, в новой версии платформы виртуализации VMware vSphere 4.1 появилась замечательная возможность создавать виртуальные машины, у которых один виртуальный процессор (vCPU) может иметь несколько ядер (Multicore vCPU). Более ранние версии VMware ESX умели представлять только одно ядро на виртуальный vCPU машины, а сама возможность многоядерности процессоров ВМ была экспериментальной.
Как известно, многие возможности VMware vSphere приходят из настольных платформ, после того, как пройдут "обкатку" пользователями на некритичных виртуальных окружениях. Например, тонкие диски или технология TPS, которая называлась просто Page Sharing, насколько я помню, пришли из VMware Workstation.
Теперь в VMware ESX 4.1 можно создавать несколько виртуальных ядер, правда не так элегантно как это реализовано в VMware Workstation 7:
Операционная система в этом случае будет видеть виртуальные ядра vCPU виртуальной машины как отдельные логические процессоры.
Чтобы сделать это в VMware ESX 4.1, нужно открыть свойства виртуальной машины, перейти на вкладку Options и выбрать категорию General в списке Advanced options. Затем нужно нажать кнопку Configuration Parameters, которая позволит изменить vmx-файл конфигурации ВМ с помощью построчного добавления параметров и их значений.
Нужно добавить вот такую строчку в качестве параметра:
cpuid.coresPerSocket
В качестве значения можно задавать число ядер на виртуальные vCPU нашей машины. При этом число ядер должно быть степенью числа 2 (то есть 1, 2, 4 или 8 ядер - про большее не упоминается в документации).
Какие требования предъявляются к виртуальным машинам с несколькими ядрами на одном vCPU:
Поддерживается в производственной среде только для VMware ESX 4.1
Virtual Machine hardware должно быть версии 7 или выше
Чтобы настроить этот параметр, нужно предварительно выключить виртуальную машину
Опция CPU hot Add/Remove будет отключена
Почему так далеко запрятана эта возможность? Ответ прост - чтобы не баловались. Потому как нужна она только в случаях, когда особенно требуется экономия на лицензировании при необходимости наращивания производительности виртуальной машины (как раз за счет числа виртуальных ядер). То есть, если ОС или приложения лицензируются на процессор (в данном случае виртуальный), то нашпиговывание его виртуальными ядрами не увеличит стоимость необходимых лицензий, но увеличит производительность ВМ.
Однако, здесь есть одно но. Необходимо внимательно читать EULA к своему развертываемому ПО в виртуальных машинах, где определены понятия сокета, процессора и ядра, в том числе, иногда и для виртуальных сред. Очень вероятно, что такой финт с наращиванием ядер будет нарушать условия EULA.
На сервере VMware ESX из состава vSphere, если запустить утилиту esxtop и перейти в категорию дисковой подсистемы (кнопка "d"), можно увидеть счетчик CMDS/s.
Что он значит? CMDS/s (Total commands per second) - это общее число SCSI - команд, передаваемых к системе хранения, включая операции ввода-вывода вывода виртуальных машин, а также сервисные команды (например, SCSI reservations). Если говорить о параметре IOPS (Input/Output Operations Per Second) - то это общее число операций ввода-вывода, представляющее сумму:
IOPS = Number of Read commands(READS/s) + Number of Write commands(WRITES/s)
Таким образом, число IOPS должно быть близко к CMDS/s, за исключением случаев, когда сервер VMware ESX активно работает с метаданными тома VMFS (например, создает и удаляет снапшоты).
RSS
